セルフマネージドActive Directory環境でRemote Desktop Services SAL (RDS SAL)の購読を試してみた

Takuya Shibata
2024.11.24
しばたです。
以前の記事でAWS Managed Microsoft ADを使ってRemote Desktop Services SAL (RDS SAL)の購読を試しました。
https://dev.classmethod.jp/articles/aws-user-based-subscription-microsoft-remote-desktop-services/
RDS SALの購読はAWS Managed Microsoft AD以外に利用者が独自に用意したActive Directory環境(セルフマネージドActive Directory)においても可能なため本記事で試してみることにしました。
 RDS SAL購読の前提条件・基本前提条件や基本的な点に関しては以前の記事と同様なので、まずはこちらをご一読ください。
https://dev.classmethod.jp/articles/aws-user-based-subscription-microsoft-remote-desktop-services/
雑に言ってしまうとインフラ的な構成はセルフマネージドActive Directoryでも変わりません。

セルフマネージドActive DirectoryだとVisual StudioとMicrosoft Officeの購読には使えずRDS SAL専用となります。

代わりに既存のActive Directory環境が使えることでその他アプリケーションやシステムにおいて柔軟に利用可能となっています。
 試してみたここからは実際に動作確認した結果を共有していきます。
 1. 検証環境 + Active Directory環境の用意今回はActive Direcotry環境の構築を楽したかったので、以前公開したこちらの環境を使うことにしました。
https://github.com/stknohg/amazon-workspaces-pack/tree/main/workspaces-trial-stack
こちらは元々Amazon WorkSpaces向けの環境構築テンプレートですが、初期状態だとADDSサーバー(兼 踏み台)が1台存在するだけなのでそのまま使えます。

Windows Server EC2に対し以下のセットアップを行ったのと等価な環境だとお考えください。
今回使用するADDS構成
# 機能の追加
Add-WindowsFeature AD-Domain-Services, GPMC, RSAT-ADDS, RSAT-AD-PowerShell, RSAT-DNS-Server | Format-List

# Active Directoryのインストール
Import-Module ADDSDeployment
$params = @{
    DomainName        = 'corp.contoso.com';
    DomainNetbiosName = 'corp';
    ForestMode        = 'WinThreshold';
    DomainMode        = 'WinThreshold';
    DatabasePath      = 'C:\Windows\NTDS';
    LogPath           = 'C:\Windows\NTDS';
    SysvolPath        = 'C:\Windows\SYSVOL';
    SafeModeAdministratorPassword = (ConvertTo-SecureString 'P@ssword' -AsPlainText -Force);
    InstallDns           = $true;
    CreateDnsDelegation  = $false;
    NoRebootOnCompletion = $false;
    Confirm = $false;
}
Install-ADDSForest @params
同時にRDS SAL購読のための前提条件を満たす様にVPCの設定(名前解決関連)を更新しています。
なお、今回の作業にAD Connectorは不要です。
 2. Secrets Manager シークレットの登録次にSecrets Managerシークレットを用意します。
前回同様license-manager-user-で始まる名称でusernameとpasswordをキーに持つ必要があります。

今回は検証なのでActive Directoryに対して全権を持つAdministratorユーザーを使い
名前 : license-manager-user-rdlicense-selfadmin
ユーザー : administrator ([email protected])
パスワード : administratorユーザーのパスワード
の設定でAWS CloudShellからCLIで作成しています。
AWS CloudShell
# AWS License Manager用のシークレットを作成
aws secretsmanager create-secret \
    --name "license-manager-user-rdlicense-selfadmin" \
    --description "Secrets for RD License Server administrative user." \
    --secret-string "{\"username\":\"administrator\",\"password\":\"P@ssword\"}"
作成結果は以下の通りです。
 3. AWS License Managerの設定変更ここからAWS License Managerの設定を行います。
マネジメントコンソールからAWS License Managerを選び、左ペイン下部にある「設定」→「ユーザーベースのサブスクリプション」を選択します。

前回の作業により既存のディレクトリ設定がある状態ですので、ここから「Active Directoryを登録」ボタンをクリックして新規設定を増やします。
ウィザードが開始されるので、ディレクトの種類を「セルフマネージド Active Directory」とし、適宜必要な情報を記載していきます。

「Active Directory のドメイン」に対象のドメイン名、「プライベート IPv4 アドレス」と「セカンダリプライベート IPv4 アドレス」に既存ADDSサーバーのIPアドレスを入力します。

今回は検証用でADDS 1台構成なので「セカンダリプライベート IPv4 アドレス」は未指定ですが、本番環境では指定する様にしてください。
次に「ネットワーキング」欄でライセンスサーバーエンドポイントを配置するVPCとサブネットを2つ選び、「シークレット」欄に前述のSecrets Managerシークレットを指定します。
「登録」ボタンをクリックしてしばらく待てばActive Directory情報が登録されます。

IDがsd-始まりで、タイプが「セルフマネージド」になっており前回とは異なることが分かります。
続けて「RDSライセンスサーバーを設定」をクリックしてエンドポイントの作成を行います。

ここでは再度「シークレット」を指定して「設定」ボタンをクリックしてやればOKです。
またしばらく待って「プロビジョニング済み」になれば完了です。
詳細は以下の通りで、タイプ以外はAWS Managed Microsoft ADの場合と同様です。
 4. ユーザーのサブスクリプションを追加するこちらは前回同様なので割愛します。

サブスクリプションを購読するユーザーをよしなに登録してください。
 5. Remote Desktop Session Host (RDSH)の設定接続用のRemote Desktop Session Host(RDSH)サーバーを用意してやります。

こちらも前回同様に以下の記事の「1. Active Directory環境にフルインストールする場合」と「2. Active Directory環境にRDSHのみインストールする場合」のパターンを参考にすると良いでしょう。
https://dev.classmethod.jp/articles/ec2-windows-remote-desktop-patterns/
くどい様ですがRDS SALはユーザーライセンスのみのため
ライセンスサーバー : Microsoft RDS ライセンスサーバーエンドポイント
ライセンスモード : 接続ユーザー数
にしてやる必要があります。
AWS Managed Microsoft AD環境の場合はVisual StudioおよびMicrosoft Office環境向けの専用グループポリシーがありましたが、セルフマネージドActive Directory環境ではその様なポリシーは無くAWSが用意してくれることもありませんでした。

このため自分でグループポリシーを作るか直接レジストリを変更する等して設定を行ってください。
 6. 動作確認今回は用意したVPC上に1台Windows Server 2022 EC2インスタンスを用意しRDSHの機能を追加して動作確認していきます。
細かい手順は割愛しますが、専用のグループポリシーが無かったのでRDSHサーバー上で直接レジストリを更新してライセンスサーバーの登録を行いました。
RDSHサーバーで実行
# 要管理者権限
# ライセンスサーバーの指定
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers" `
    -Name SpecifiedLicenseServers -Value "xxxxxxxxxxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.aws-license-manager-license-server.amazon.com" `
    -PropertyType MultiString

# ライセンスモードの指定 (4 : 接続ユーザー数)
$obj = Get-WmiObject -Namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.ChangeMode(4)
「RDライセンス診断機能」から適用状況を確認すると以下の通りです。
セルフマネージドAcitve Direcotryの場合は利用可能なライセンス数が9,999でした。

初期状態で十分な数を用意するのはAWS Managed Microsoft ADの時と同様ですが数量が異なる理由はよくわかりません...
あとはRDS SALをサブスクライブしたユーザーでRDP接続してやるだけです。
 余談1 : RDS SALの自動購読についてセルフマネージドAcitve Direcotryの場合もRDS SALの自動購読が発生しました。

AWS Managed Microsoft ADの時より購読の判定に時間がかかった様な気がしますが、厳密に計測できなかったので正直何とも言えない感じです。
 余談2 : RD Licensing Serverの所属OUセルフマネージドAcitve Direcotryの場合、ドメイン直下にLicenseServer OUが作成されRD Licensing Serverの実体が登録されていました。
上図ではコンピューターオブジェクトが3つありますが、これは、最初Acitve Direcotryを登録した時点でWindows Server 2019のコンピューターが1台登録されたためです。


最初の登録時点ではWindows Server 2019が1台登録される
「RDSライセンスサーバーを設定」した時点でWindows Server 2022が2台追加され合計3台になります。

このためVPCには3つのENIが生える形になります。
前述の通り専用のグループポリシーは提供されないため、このOUには何のポリシーもリンクされていません。


LicenseServer OUにグループポリシーはリンクされていない
ちなみに今回は試していませんが、既存のLicenseServer OUがある状態で今回の登録作業を行うとエラーに成る予感がします...

現状OUの作成先を変更することは出来ないので気を付けておくと良いでしょう。
 最後に以上となります。
手順としてはAWS Managed Microsoft ADの時と同様でした。

注意点も同様でサブスクリプションの自動購読が行われまますので操作ミスにはご注意ください。